Proximity-based applications and proximity services (ProSe) represent a fast growing social and technological trend that may have a major impact on the evolution of cellular wireless/mobile broadband technologies. These services are based on the awareness of two devices or two users being close to each other and may include such applications as public safety operations, social networking, mobile commerce, advertising, gaming, etc. D2D discovery is the first operation to enable D2D service. D2D communication is being studied in communication standards groups to enable discovery and data communication services between user equipments (UEs). During the D2D group communication, a transmitting D2D UE can transmit data packets to one or more D2D UEs belongs to a group or broadcast data packets to all the D2D UEs in proximity or send unicast data packets to a specific D2D UE. A destination identifier (ID) in the transmitted data packet identifies the intended recipient of the data packet. The destination ID can be one of unicast ID, broadcast ID or Group ID.
During ProSe-based D2D group communication, the data being transmitted within the group should be secured (i.e., confidentiality protected) from non-group UEs. In order to support the security, various types of keys with a hierarchy are generated and provided to the UEs which are members of a group, so that only the members of the ProSe group can participate in the communication.
FIG. 1 illustrates a diagram depicting a key hierarchy for D2D group communication according to the related art.
Referring to FIG. 1, a ProSe group key (PGK) 102 is defined, wherein the PGK 102 can be specific to a group of D2D UEs. Multiple PGKs per group can be pre-provisioned in UE. Each of these PGKs for the same group is identified using an 8 bit PGK ID. Each PGK 102 also has an associated expiry time. If any UE within the group wants to send data packets to one or more other UEs of the group, then a ProSe traffic key (PTK) 104 can be derived from the PGK 102 corresponding to that group using a key derivation function (KDF). The PTK 104 is identified using a PTK ID. The PTK 104 is a group member specific key generated from the PGK 102. Each PTK 104 is also associated with a 16 bit counter, wherein the counter specifies the packet count. For encrypting data, <PTK, Counter> needs to be unique. The counter is updated for every packet transmitted. If the counter rolls over then a new PTK 104 is generated from the PGK 102.PTK=KDF(PGK, PTK ID, group member identity of transmitter).
Further, a ProSe encryption key (PEK) 106 is also generated whenever PTK 104 is generated.PEK=KDF(PTK, Algorithm ID),
wherein the Algorithm ID identifies the security algorithm. The PGK ID, PTK ID and counter values are transmitted along with the encrypted data packet.
During the data transmission, an internet protocol (IP) packet is received from the upper layer. The IP packet (or packet data convergence protocol (PDCP) service data unit (SDU)) is first processed by a PDCP entity. The PDCP entity applies the header compression, sequence numbering and security to the PDCP SDU and generates the PDCP protocol data unit (PDU). The PDCP PDU (or radio link control (RLC) SDU) is then processed by an RLC entity. The RLC entity performs fragmentation functions and generates the RLC PDU. The RLC PDU (or medium access control (MAC) SDU) is then used by a MAC entity to generate the MAC PDU. The MAC PDU is then transmitted by the physical layer on the radio channel. During the data transmission, a UE may be transmitting to multiple destinations concurrently. Therefore, multiple PDCP/RLC entities are created. One PDCP entity and RLC entity corresponds to one destination and processes the packets corresponding to an associated destination.
During the data transmission, the UE can also transmit different types (e.g., voice, data) of data traffic to the same destination (for example to same group ID). So, multiple PDCP and RLC entities are created corresponding to same destination. In the MAC layer, a MAC SDU or an RLC PDU corresponding to different RLC entities is identified using a logical channel identity (LCID). The LCID is included in the MAC layer in the MAC header. As per the current specified key hierarchy, one PTK and one counter are used by a transmitter for one destination. This works when there is only one PDCP/RLC entity in the transmitter corresponding to the destination wherein the counter is the same as a PDCP sequence number (SN) and one PTK corresponding to the destination. If there are multiple PDCP/RLC entities per destination, then enhanced methods are needed for counter and PTK maintenance (for example, to prevent reuse of same PEK and count as input for encryption). That is, the current scheme has a limitation in that it cannot support multiple PDCP entities per destination.
So a method of counter and security key maintenance in a system in which a UE can transmit different traffic types or traffic of different priority to the same destination (and hence has multiple PDCP/RLC entities per destination or per group ID) is needed.
Further, it is possible to mount a replay attack on a particular ProSe communication, since any UE can transmit the packet and there is no signaling between the UEs before communication. Considering the sensitivity of ProSe public safety communication, a replay attack is a big security threat. So a method of mitigating the security threat in a system in which a UE can transmit user traffic directly is also needed.
The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present disclosure.